Enterprise networks are complex environments, with numerous components often under the control of teams outside the security team. During an incident, it is critical that respondents understand the network topology and have the most current network policy and device information available to them. Network documentation is often incomplete and out-of-date; security teams need a way to quickly and efficiently gather actionable network intelligence to effectively respond to a security incident.
This blog will cover some of the current challenges faced by security operations teams and how they can harness the vast amounts of network intelligence available, such as device, policy and path information, using Tufin as a case study. By integrating with Tufin Orchestration Suite, DFLab’s IncMan SOAR platform can utilize its R3 Rapid Response Runbooks to enable the collection of actionable network intelligence, along with its automation, orchestration, and measurement power to respond faster and more efficiently to security incidents.
There are three specific challenges that are common within any security operations center and analysts need to be able to find an effective and efficient way to solve them and obtain the information they need as quickly as possible.
- How can I get a current list of network devices?
- How can I get a current list of rules and policies?
- How can I determine the network path from source to destination?
The DFLabs and Tufin Solution
Tufin Orchestration Suite takes a policy-centric approach to security to provide visibility across heterogeneous and hybrid IT environments, enable end-to-end change automation for network and application connectivity and orchestrate a unified policy baseline across the next generation network. The result is that organizations can make changes in minutes, reduce the attack surface and provide continuous compliance with internal and external/industry regulations. The ultimate effect is greater business continuity, improved agility and reduced exposure to cyber security risk and non-compliance.
Tufin Orchestration Suite together with DFLabs IncMan SOAR platform provides joint customers with an automated means to gather actionable network intelligence, a task which would otherwise need to be performed manually, taking up valuable analyst time when every minute counts. This results in an overall decrease in the mean time to respond (MTTR) to a computer security incident, saving the organization both time and potential financial and reputation loss.
It provides a list of current network devices based on any number of criteria, a list of current rules and policies for any number of devices and is able to simulate network traffic from source to destination, including path and associated rules. Here is a use case in action to see exactly how!
Network traffic between a workstation and a domain controller has been identified as potentially malicious by the organization’s UBA platform. The UBA platform generated an alert which was forwarded to IncMan SOAR, causing an incident to be automatically generated. Based on the IncMan Incident Template, the following R3 Runbook was automatically assigned and executed to gather additional network intelligence.
The information gathering begins by simulating the network path between the source address and destination address of the potentially malicious network traffic. This information is gathered by two separate Enrichment actions, one which will display this information in a table format, and another which will display the same information in a graphic network path which can be exported and shared or added to reports.
As with information from any other IncMan Enrichment action, each network device on the path between the source address and the destination address is stored within an array which can be used by subsequent actions.
After the path information has been retrieved, an additional Enrichment action is used to retrieve information about each device along the path. This includes information such as device vendor, model, name and IP addresses.
Following the acquisition of the device information, two additional Enrichment actions are utilized to gather additional network intelligence. The first action will retrieve all rules for each network device along the path. Detailed information on each matching rule will be displayed for the analyst, allowing the analyst to assess why the traffic was permitted or denied, what additional traffic may be permitted from the source to the destination, and what rule changes may be appropriate. The second action will retrieve all policies for each network device along the path. Similar to the previous rule information, this information will allow the analyst to assess the configured network policies and determine what, if any, policy changes should be made to contain the potential threat.
Harnessing the power of Tufin Orchestration Suite, along with the additional orchestration, automation and response features of DFLab’s IncMan SOAR platform, organizations can elevate their incident response process, leading to faster and more effective response and reduced risk across the entire organization.
To see the integration in action, request a demo of our IncMan SOAR platform today.
In our previous two blogs, we looked at some of the most common problems a Security Orchestration, Automation and Response (SOAR) Technology is designed to solve and the three pillars of a SOAR solution. We will round out this three-part series by taking a more detailed look at some of the most critical SOAR Technology components any SOAR solution should possess. While some of these components may be more critical than others to individual organizations, each plays an important role in the overall function of a SOAR solution and should be considered when evaluating different platforms.
1. Customizability and Flexibility
No two security programs will be alike; this is especially true when you cross vertical lines. For a SOAR solution to be effective, it should be capable of being the single tool on top of the security stack. A SOAR solution should be able to be implemented in a manner that is optimized for CSIRT teams, as well as SOCs, MSSPs and security teams. Data input from a multitude of sources, including machine to machine, email, user submissions and manual input should be supported. The importance of security metrics means that customers should be able to customize not only the values available in the solution but also what attributes are tracked as well.
The number of security solutions, commercial, open source, and developed in-house means that any viable SOAR solution must be flexible enough to support a multitude of security products. Any SOAR solution will support many security products out of the box, however, the likelihood that all the organization’s security products will be supported by default is low. For that reason, it is crucial that a SOAR solution has a flexible option in place that allows customers to easily create bi-directional integrations with security products which are not supported by default.
2. Process Workflows
One of the key benefits of a SOAR solution is being able to automate and orchestrate process workflows to achieve force multiplication and reduce the burden of repetitive tasks on analysts. To achieve these benefits, a SOAR solution must be able to support flexible methods for implementing process workflows. The implementation of these workflows must be flexible enough to support almost any process which may need to be codified within the solution. Workflows should support the use of both built-in and custom integrations, as well as the creation of manual tasks to be completed by an analyst. Flow controlled workflows should support multiple types of flow control mechanisms, including those which allow for an analyst to make a manual decision before the workflow continues.
3. Incident Management
Incident response is a complex process. Orchestration and automation of security products provide obvious value to any security program, but to maximize the time and monetary investment in a SOAR solution, a comprehensive SOAR solution should include additional features to manage the entire incident response lifecycle. This should include basic case management functionality, such as tracking cases, recording actions taken during the incident and providing reporting on critical metrics and KPIs. This should also include other ancillary functions such as detailed task tracking, evidence, and chain of custody management, asset management, and report management.
4. Threat Intelligence
Actionable threat intelligence is a critical component in effective and efficient incident response. While simple threat intelligence feeds still provide some value and should be supported by a SOAR solution, to be truly effective in today’s threat landscape, threat intelligence must go above and beyond simple feeds. Because a SOAR solution has access to not only the indicators but also the rest of the incident information which can provide the additional context, it is in a unique position to gather actionable threat intelligence.
A proactive security program requires threat intelligence to be properly correlated to discover attack patterns, potential vulnerabilities and other ongoing risks to the organization. This correlation should be done automatically and it should be immediately clear if an ongoing incident may share common factors with any previous incidents. Because threat intelligence can consist of a vast amount of data, visual correlation is also an important factor when assessing threat intelligence capabilities.
5. Collaboration and Information Sharing
Incident response is not one player sport. Response to a security incident will likely include multiple individuals and potentially multiple teams and even organizations. To be effective in a team environment, a SOAR solution must support seamless collaboration and information sharing among team members in a controlled manner.
Collaboration and information sharing must also be possible outside of the organization itself. This is especially true in the context of threat intelligence. Open sharing of threat intelligence, when possible, it a critical tool in fighting cybercrime. There are numerous avenues available to share threat intelligence, open, closed and industry-specific. The majority of these threat intelligence sharing programs utilize one of the open standards for threat intelligence, such as STIX/TAXII, OpenIOC or MISP, and each of these standards should be supported by a SOAR solution.
For more information on any of these topics covered in this three-part series, please check out our whitepaper “Security Orchestration, Automation, and Response (SOAR) Technology” here.
Earlier this year I was talking to a colleague about the state of SOC operations and how I was looking forward to going to the SANS Security Operations Summit in New Orleans in July. The folks who attend SANS events are at the top of their game and let’s be honest, SANS provides some of the best training in our industry, so what’s not to love?
The conversation quickly turned to how to provide better scalability within SOC operations. Given that our teams are confronted with an increased number of alerts coming from more sophisticated actors on a daily basis, how do we keep up? We spoke about the need for better security automation to enrich the information available at the onset of an incident and how malware has been automating since the Morris worm 30 years ago.
At one point she asked me how best we can handle the transfer of incident handling “tribal knowledge” from the senior Incident Response personnel to the junior members, given the daily workload they carry. I thought about it for a moment and threw out that perhaps increased spending for machine learning or AI could help bridge the knowledge gap. She then asked, “Couldn’t we take that money and invest in knowledge transfer within the team instead?”. That simple and simultaneously complex question got me to thinking about how we can better utilize existing resources to provide that knowledge transfer in an environment as dynamic and rapidly changing as an Incident Response organization.
I thought this topic was interesting enough to make it my focus for my upcoming speaking engagement at SANS.
As we already know an increased workload coupled with an industry-wide shortage of skilled responders is heavily impacting operational performance in Security Operations Centers (SOC) globally and an integral part of the solution is formulating a methodology to ensure that crucial knowledge is retained and transferred between incident responders. By utilizing Security Orchestration, Automation and Response (SOAR) technology, security teams can combine traditional methods of knowledge transfer with more modern techniques and technologies.
Join me at the SANS Security Operations Summit on July 30, 2018 at Noon for an informal “Lunch and Learn” session to discuss how we ensure that the Incident Response knowledge possessed by our senior responders can be consistently and accurately passed along to the more junior team members while simultaneously contributing to the Incident Response process. I look forward to meeting you there.
If you are not attending the summit, don’t worry, you can visit our website to find out more information about the benefits of utilizing a SOAR solution with DFLabs’ IncMan SOAR platform. Alternatively, if you would like to have a more in-depth discussion, you can arrange a demo to see IncMan live in action.
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.
“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.
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.
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.
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.
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.
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.
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.
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.
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).
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.