IncMan SOAR v4.5 – With New Open Integration Framework for Enhanced Customization

DFLabs is thrilled to announce the release of the latest version of its award-winning and industry leading Security Orchestration, Automation and Response (SOAR) solution, IncMan SOAR version 4.5.  

IncMan SOAR version 4.5 includes some of our most exciting enhancements to date. Many of the most significant new features in this latest release are centered around DFLabs’ commitment to delivering a more open, extensible and community-oriented solution to some of the most challenging problems facing SOCs, CSIRTs and MSSPs today. Stay tuned into our website in the coming months, as we will be announcing several other new features and programs centered around creating a more open, community solution soon!

As part of this latest release, DFLabs has added many new integrations across a wide variety of product spaces including ITSM, vulnerability management and threat intelligence. This includes integrations with AlienVault OTX, RSA NetWitness, ServiceNow and Tenable. We have also enhanced several of our existing integrations, including those with IBM QRadar, Splunk and TAXII.

You have asked, and we have listened; version 4.5 will include a significantly expanded REST API, allowing users to extend the functionality of IncMan SOAR and integrate it into other processes in new and exciting ways. Over the next several releases, DFLabs will continue to add new functionality to its API, allowing even greater extensibility for our customers and integration partners.

We have expanded the functionality of our one of a kind START Triage Module in version 4.5 as well. START Triage can now accept inputs from any of our supported data ingestion methods, including syslog, email and the API.  With this increased support, IncMan SOAR users now have highly granular control over which events are forwarded to the START Triage module for enrichment and validation and which events are converted directly into incidents.

Without a doubt, our most exciting and innovative feature in this latest release is IncMan SOAR’s new Open Integration Framework.  The DFLabs Open Integration Framework will fundamentally change the way integrations can be used and extended within the platform. Close, proprietary integrations are out and open, text-based integrations are in. The DFLabs Open Integration Framework allows integration code to be defined in any of our supported scripting languages: Bash Perl, PowerShell, and Python, along with all the other components that make an integration tick within a SOAR solution.

From version 4.5 onward, DFLabs will be developing all integrations in this new Open Integration Framework, giving customers full visibility into the integrations, as well as the ability to extend these integrations. Of course, this Open Integration Framework will also allow customers to develop their own integrations from the ground up as well.

One of the key differentiators in DFLabs’ approach to providing an open framework for integration development is the action level approach taken in this framework. The DFLabs Open Integration Framework defines all integrations at the action level, not as one monolithic file. This action level definition makes the DFLabs Open Integration Framework much more accessible to users with more limited coding experience. It also allows users to easily add actions to existing integrations without the need to modify existing code and enables portability and sharing at the action level. Execution of each integration in a unique Docker container, easily configured from within the integration file, provides additional security and eliminates the risk of conflicting libraries.

For more information on DFLabs Open Integration Framework and other features of IncMan SOAR version 4.5, register for our upcoming webinar on Nov 27th at 3pm GMT and check out our new short overview video.

Make sure to stay tuned in as DFLabs will be releasing some other exciting news focused on increased community involvement soon!

SOAR vs. Orchestration and Automation: What’s the Difference?

If you’re playing buzzword bingo in 2018, Orchestration and Automation (O&A) are two words you want to see on your card. Unlike some buzzwords, O&A are not just fluff; when implemented properly, Orchestration & Automation are real solutions which can provide tremendous benefits to overworked security teams.

However, as the industry starts to see real benefits emerge in new classes of solutions, more and more products start to incorporate aspects of that solution into their existing products. This tends to muddy the waters in the product space and leaves potential customers confused (talk to a SIEM vendor if you want to hear someone else’s perspective on this problem).

Before we go any further, let me clarify something; this blog is not intended to be a shot at anyone’s marketing or any vendor incorporating Security Orchestration and Automation into their existing product. To the contrary, when implemented properly, Automation and Orchestration can benefit customers at many levels. If you’re in a product space where O&A can provide value to your customers, you should absolutely be looking into it. Instead, this blog is intended to answer the question we are getting asked more and more recently; “I see vendor X is doing orchestration and automation now, are they your competitor? How are you different?”

Orchestration and Automation

In terms of O&A, there are two main categories of solutions (of course, there are always some that fall somewhere in the middle:

  1. Security Orchestration, Automation and Response (SOAR) solutions
  2. Other solutions which have implemented some level of Orchestration and Automation into their existing (non-SOAR) solutions

When you begin to compare these two categories, there are two significant differentiators. Non-SOAR solutions tend to focus on O&A within their own product, or within a similar product space (let’s use vulnerability management as an example). Their focus on one particular product space tends to make them very capable of addressing advanced use cases in that product space, however, they typically do not support use cases outside of that space. A SOAR solution, on the other hand, should be capable of performing O&A across many different product spaces in one cohesive solution.

The other significant differentiator between SOAR and non-SOAR solutions is their ability to perform other Response (the R in SOAR) and incident management functions. Whereas a SOAR solution should be able to perform these other Response functions, a non-SOAR solution is typically limited in this regard.

Which is the right solution?

As always, it depends on the problem you are trying to solve.  If you are trying to increase your efficiency in vulnerability management, threat intelligence, endpoint detection or network management, a non-SOAR solution in one of these spaces with O&A capabilities may be the right solution for you.  If you are trying to solve inefficiencies across all of these spaces, you may want to invest in a SOAR solution. Of course, there is also nothing wrong with layering these technologies either; perhaps a focused solution which includes O&A is required in one space, which can then be orchestrated with other security products through a SOAR solution.

So, getting back to answering the original questions, “I see vendor X is doing orchestration and automation now, are they your competitor? How are you different?” If vendor X is not a SOAR solution provider, there is probably some overlap, however, they are usually focused on solving a different or more specific problem to DFLabs, so they are most likely not a competitor. In fact, in some cases, they may be a technology partner. In these cases, our core differentiators are usually those listed above. If vendor X is a SOAR solution provider, they may very well be a competitor and our core differentiators will depend on the specific vendor.

In either case, DFLabs would be happy to discuss its differentiators from other SOAR solutions in a more personalized way, so if you have any questions or would like a one to one demo of our IncMan SOAR platform, please do get in touch. However, I wanted to take a few minutes out of the day to address this common question you may have as you start your journey down the O&A road.

Using Threat Intelligence Effectively in Security Automation and Orchestration with DFLabs and Cisco Security

When a security incident occurs, it is unlikely that the entire scope and chain of events will be obvious from the outset. More often, it is a single indicator or security alert which provides the first inkling that something is wrong. This is especially true for more advanced, complex, or targeted attacks. It is the security team’s responsibility to take that small, possibly benign event, and determine if it is indeed an incident (triage), and if so, the full scope and impact of the incident (investigation).

Security teams often rely on threat intelligence during both the triage and investigation stages of an event.  This information can be critical in determining the veracity of an alert and then pivoting from that first indicator to quickly determine the scope of the potential cyber security incident. For example, an endpoint alert for a suspicious file may provide a hash value, but little else. Manual analysis of the file will likely provide additional indicators, however, very few organizations have the time or resources to manually analyze each suspicious file they encounter. Threat intelligence can quickly add context to that first hash indicator; perhaps informing analysts that that file is a known dropper for another malicious file which may not have been detected by the endpoint solution, as well as providing IP addresses or domains to which the dropped file is known to have communicated with in the past. Online sandboxes can also be used to provide this kind of threat intelligence in near real-time, much faster and more cost-effectively than manual analysis.

How can threat intelligence be an effective tool?

For threat intelligence to be an effective tool, it must be both reliable and actionable.  In the case of threat intelligence, reliable means that we are able to rely on the accuracy and completeness of the intelligence with a high degree of confidence.  Actionable in this case means that the intelligence must be something that enables us to take some action, further investigation, containment etc., which we would not have been able to take without the threat intelligence.  By definition, threat intelligence cannot be actionable if it is not reliable. For example, a threat intelligence source that classifies 8.8.8.8 (Google’s DNS) as malicious because a malware sample made a DNS request to this IP should not be considered reliable, and therefore we would not want to take action on intelligence from this source.

Reliable, actionable threat intelligence is the backbone of successful security automation. Where human analysts can determine the reliability and actionability of threat intelligence for each query, automation can be much less forgiving.  For this reason, it is even more critical that there is a high degree of confidence in the source of threat intelligence when used in automation.

Still, when a high confidence threat intelligence source is combined with well-executed automation and orchestration processes, the result is a level of efficiency that simply cannot be achieved using strictly manual processes,  The “query, investigate, pivot, repeat” can take many minutes or even hours when performed manually, but is often a very predictable and repeatable process which can be automated and completed in significantly less time. This allows analysts to focus their limited time on the portions of an investigation which require human analysis instead of the arduous data gathering and enrichment processes.

DFLabs and Cisco Use Case

As an example, let’s examine a malware analysis automation use case using a Runbook from DFLabs IncMan SOAR and several Cisco security products.  This use case focuses strictly on the analysis of a malicious file, it is not dependent on the source of the file such as an attachment seen by Cisco Email Security.  This same Runbook could be used with other automated runbooks as part of the response to an endpoint alert, malicious email attachment or other security event.

The Runbook begins by using Cisco Threat Grid to perform advanced sandbox analysis of the file to gather intelligence which can be used to further enhance and pivot the investigation.  In this example use case, we will focus primarily on network indicators and threat intelligence to demonstrate the way in which automation can be used to pivot from indicator to indicator.

Follow the detonation and report from Cisco Threat Grid, this Runbook will perform basic enrichment actions on any IP addresses the malware sample was observed to be communicating with, such as WHOIS and geolocation queries.  Following these basic enrichment actions, the Runbook will query Cisco Threat Grid for IP reputation information for each of the IP addresses. If Cisco Threat Grid returns negative reputation results exceeding a user defined threshold, the IP address will be automatically blocked at the firewall.  The organization’s solution will then be queried to see if any hosts have been observed making connections to the malicious IP addresses. If the EDR solution returns results, the analyst will be presented with a User Choice decision, allowing the analyst to review the previously enriched information and make a manual decision as to whether to quarantine the host until further investigation can be completed.

Cisco Malware Analysis

 

Simultaneously, the Runbook queries Cisco Umbrella Investigate for domains associated with the IP addresses found during the executable analysis by Cisco Threat Grid.  If any domains are found, a similar process to that performed on the IP addresses is performed; basic enrichment followed by a threat intelligence query and a domain detonation using Cisco Threat Grid.  If Cisco Threat Grid returns negative reputation results exceeding a user defined threshold, the domain will automatically be blocked using Cisco Umbrella. As with the IP addresses, the EDR solution is then queried and any results will cause a User Choice decision to be presented to the user to consider quarantining the host until further investigation can be completed.

The final simultaneous action is a query of the EDR solution for evidence of execution of the executable’s hash value returned by Cisco Threat Grid.  Any results will cause a User Choice decision to be presented to the user to consider quarantining the host until further investigation can be completed.

In this use case, User Choice decisions were used before quarantining hosts was performed to show how manual decision points can be used to enhance the confidence in Runbooks which may perform tasks which could have a negative impact on the environment, such as quarantining a host.  These User Choice decisions could easily be automated decisions, depending on the preference of the organization. Conversely, the automated decisions made to block the IP addresses and domains could easily be made User Choice decisions.

This example use case shows how a time consuming manual process like pivoting from malware analysis to indicators across the network can be easily automated, saving analyst time while not compromising the final outcome of the process, by utilizing reliable and actionable threat intelligence.  

By combining the vast capabilities of Cisco’s suite of security products, with the orchestration and automation power of DFLabs’ IncMan SOAR platform, organizations can respond to potential security incidents, with unmatched speed and accuracy.

To learn more about using threat intelligence effectively in Security Automation and Orchestration with Cisco Security, register now for our upcoming webinar on Tuesday October 30, at 11am EST / 4pm CET hosted by myself with guests Jessica Bair, Senior Manager, Advanced Threat Solutions, Cisco Security and Michael Auger, Senior Security Solutions Architect, Cisco Security.

Add Context and Enrich Alert Information for a More Effective Response with DFLabs and ArcSight

Responding to a new security incident in the fastest possible time frame is critical for any security operations center (SOC) or computer security incident response team (CSIRT), but having the necessary information at your fingertips is key in order to help improve response times and appropriately deal with the threat at hand. In this blog post we’ll take a closer look at how security teams can increase the efficiency and effectiveness of their response by adding context and enrichment to the alert information directly from ArcSight, when utilizing DFLabs’ Security Orchestration, Automation and Response (SOAR) platform and its many other bidirectional integrations.

The Problem

Organizations are generating more log data than ever before and are increasingly turning to SIEM tools to help manage, correlate and alert on potential events from this large quantity of data. Once data is correlated and an alert is generated, enriching alert data is often a manual task which consumes a significant amount of analysts’ time. Pivoting from a single alert or from enriched information is often also a manual process, requiring many more custom written queries within the SIEM. Enriched and additional data must then be correlated manually by the analyst before it becomes actionable.

On a daily basis an analyst will face a number of challenges and is likely to be asking themselves the following questions:

  1. How can I use the SIEM logs to add context to a security event?
  2. How can I enrich information from the initial security alert?
  3. How can I pivot from the initial security alert to further my investigation?
The DFLabs and ArcSight Solution

DFLabs and MicroFocus ArcSight bring SOAR and SIEM together to allow rapid, informed responses to security incidents based on enriched, actionable information. DFLabs’ IncMan SOAR platform allows users to automatically query ArcSight to pivot from an initial alert to gather increase insight into the activity within the organization. IncMan also allows users to enrich information retrieved from ArcSight, such as IP addresses, hostnames and domains, using any number of IncMan’s other integrations.

About MicroFocus ArcSight

ArcSight is an industry-leading Security Information and Event Management (SIEM) solution from MicroFocus. ArcSight collects and analyzes events from across systems and security tools. It detects security threats in real time so that analysts respond quickly, and it scales to meet demanding security requirements. ArcSight’s advanced distributed correlation engine, helps security teams detect and respond to internal and external threats, reduces response time from hours or days to just minutes.

Use Case

To get a real understanding of how the two solutions work together, here is a simple use case in action.

A Web Application Firewall (WAF) has observed a potential attack against an application server in the organization’s DMZ. IncMan automatically responds by initiating an appropriate runbook for the alert. The runbook begins by performing basic enrichment on the source IP address of the malicious traffic. This basic enrichment is followed by a query for IP reputation information on the source IP address from the organization’s threat reputation service of choice.  

Following the threat reputation search, ArcSight is queried for any other events which have been recently generated by the source IP address. If ArcSight returns any other recent events generated by the source IP address, or the source IP address has a negative threat reputation, the severity of the incident is automatically upgraded to High. The analyst is then presented with a user choice decision to determine if the source IP address should be blocked at the perimeter firewall. If the analyst chooses to automatically block the source IP address, a ticket will be created in ArcSight Enterprise Security Manager (ESM) to notify the appropriate teams to follow up on the emergency change according to the organization’s policies.

These actions are followed by a second query to ArcSight, this time for any other recent events involving the web application server. If ArcSight returns any other recent events generated from the web application server, the severity of the incident is automatically upgraded to High (unless it has already previously been upgraded).  The runbook concludes by performing a query of the organization’s endpoint detection solution for all recent events from the web application server. This information will be retained for review by the analyst during the investigative process.

ArcSight

 

ArcSight Actions

In summary, here are the actions available to security analysts by using ArcSight.

Enrichment:

  • Get Active List Entries
  • Search Into Events

Containment:

  • Add Active List Entries
  • Clean Active List Entries

Notification:

  • Create Ticket
  • Get Ticket
  • Update Ticket

Integrating ArcSight with DFLabs’ IncMan SOAR allows organizations to efficiently triage the volume of alerts being generated by the SIEM, automatically prioritizing those alerts which may pose the greatest risk to the organization. By automating and orchestrating the SIEM with other security solutions, IncMan SOAR can automatically enrich the alert information, then pivot based on the enriched information as an analyst would do during a manual investigation. This ability to automatically enrich and pivot allows IncMan to more accurately prioritize incidents which may initially seem innocuous.  

Automatic Observable Harvesting With IncMan SOAR

As soon as the first indicator of compromise is located, the most common next step is to try to pivot from that indicator to find additional indicators or evidence on the network. While it is sometimes necessary to perform your own research to determine what additional indicators may be present, it is common to make use of previous research when looking for new indicators to hunt for.

This is especially true when dealing with an indicator of malicious software.  Perhaps you have found a host communicating with an IP address known to be associated with a particular malware variant; the logical next step would be to search for communication with other IPs, domains and URLs the malware may be associated with, along with looking for the host-based activity the malware is known to use.

For example, suppose an IDS alerted on the IP address 144.202.87[.]106.  A quick search on VirusTotal indicates that this IP address may be malicious, however, it does not provide much information which could be used to pivot to other indicators.  So where does every good analyst turn at this point? Google, of course! A quick Google search for the IP address returns several results, including a blog post from MalwareBytes on the Hidden Bee miner. 

Along with a detailed analysis of the Hidden Bee miner, the post also includes several other IP addresses and URLs which analysts observed in this attack.  Now we have some data to pivot and hunt with!

This entire analysis from the MalwareBytes team can easily be added into DFLabs’ IncMan SOAR platform by copying and pasting the blog into the Additional Info section of the incident.  In addition to allowing this information to be accessed by the working on this incident, adding this text to the Additional Info field has an additional advantage we have not yet discussed; Automatic Observable Harvesting.

When text is added to a field such as the Additional Info fields in IncMan, Automatic Observable Harvesting will automatically parse through the text and attempt to harvest observables from the unstructured text.

In the case of the Hidden Bee analysis from MalwareBytes, Automatic Observable Harvesting automatically harvested four IP addresses, a URL and a domain from the unstructured text and added them to the observables section.

While six observables may not take long to manually enter into the platform, it is not uncommon to find detailed malware analysis that contains dozens of IP addresses, hash values, domains, and other observables. Entering this many observables into IncMan manually in order to take advantage of IncMan’s automation and orchestration features on the new observables would be a time-consuming process. Automatic Observable Harvesting performs this task automatically.

Once these new observables are added into IncMan, analysts can take advantage of IncMan’s automation and orchestration features to begin performing additional enrichment on the observables, as well as searching across any internal data sources for evidence of the observables and blocking them if needed.

If you would like to see IncMan SOAR from DFLabs in action, including its Automatic Observable Harvesting functionality, get in touch to arrange and see one to one demo now.

Automate Evidence Gathering and Threat Containment by Orchestrating Response Efforts with Carbon Black Defense

The integration between DFLabs’ IncMan R3 Rapid Response Runbooks and Carbon Black Defense’s next-generation antivirus and EDR solution allows companies to automate evidence gathering and threat containment efforts, and cut dwell times down to a manageable level.

Equipped with strong evidence data gathered from Carbon Black Defense, analysts and security teams can quickly disposition and act to remediate an incident. Carbon Black Defense uses their award-winning Streaming Prevention technology to take a holistic approach to an organization’s critical infrastructure.

The Problem

Sophisticated attacks that organizations have been experiencing cause traditional antivirus to become ineffective. Signature-based detection mechanisms can still detect known threats, but the new generation of non-malware attacks are going undetected in our networks and lying dormant for extended periods of time, enabling attackers to use our environments as their own personal playground.

To manage these deficiencies, Security Operation Centers are employing a wider range of tools to close the gap created by their antivirus solution. Evidence gathering across these tools have added to an analyst’s investigational times, which are allowing our adversaries ample time to secure their foothold in our networks.

Three common problems include:

  1. Attack vectors have morphed from file to file-less tactics which have caused traditional, signature-based antivirus to no longer be an effective detection mechanism
  2. Dwell time is being measured in days which have exceeded triple-digit figures
  3. Manual evidence gathering costs Security Operations teams valuable time when investigating possible incidents
DFLabs and Carbon Black Solution

An incident can turn into a breach in a few minutes, and this makes early detection and remediation a crucial aspect of an organization’s security program. Utilizing IncMan’s integration with Carbon Black Defense allows organizations to automate evidence gathering at their endpoints and present their analysts with critical information such as running processes, system information, and historical event detail to accelerate their decision-making ability to quickly remediate an issue.

These remediation tasks range from terminating processes on a victim machine to completely removing it from the network to allow for hands-on investigation and recovery.

About Carbon Black Defense

Carbon Black Defense is a next-generation antivirus and endpoint detection and remediation solution which utilizes Carbon Black’s proprietary Streaming Prevention technology to protect organizations from the full spectrum of malware and non-malware attacks.

By leveraging event stream processing, Streaming Prevention in Carbon Black Defense continuously updates risk profiles made from endpoint activity and when multiple potentially malicious events are observed, Carbon Black Defense will take action to block the would-be attack. This next-generation antivirus solution is proving why Carbon Black Defense will be the industry’s de facto standard in the following years.

Use Case

An IDS alert is received and triggers an incident in IncMan. Through an R3 Rapid Response Runbook, enrichment actions are initiated by first querying IP reputation services for the source of the suspicious activity. A second IP reputation service is then queried to verify the results of the first query. Once the reputation checks have been completed, the priority of the incident is set according to the results of the reputation checks and a ticket is opened in the organization’s ticket management system.

IncMan continues to process the runbook by gathering additional enrichment data for the incident handler. User account information is pulled from Active Directory and Carbon Black Defense is queried to collect system information, including all running processes on the victim machine. In addition to system information, IncMan also queries Carbon Black Defense events from the victim machine observed in the last 30 days.

Once the enrichment information is gathered, the incident handler will receive notification of the incident. The incident handler will be prompted with a User Choice decision to determine if containment actions may be appropriate. The incident handler can review the information gathered up to this point to determine if automated containment actions should be performed at this point. If the incident handler determines the activity is malicious and automated containment actions are appropriate, the machine will be quarantined from the network and the source address will be blocked at the firewall.

Carbon Black Defense Actions

Enrichment:

  • Directory Listing
  • Download File
  • Event Details
  • List Processes
  • Memory Dump
  • Policies List
  • Search Into Events
  • Search Process
  • System Info

Containment:

  • Change Device Status
  • Delete File
  • Terminate Process
Summary

Carbon Black Defense is an extremely powerful endpoint solution, capable of detecting advanced threats, supporting detail data enrichment, and enabling rapid incident response. Orchestrating actions between Carbon Black Defense and other third-party solutions through IncMan integrations allows organizations to harness the power of Carbon Black Defense at any stage of the incident response process, providing a more efficient and effective response process.

Contain Threats and Stop Data Exfiltration with DFLabs and McAfee Web Gateway

Security teams are inundated with a constant barrage of alerts. Depending on the severity of each alert, it is often minutes to hours before an analyst can properly triage and investigate the alert. The manual triage and investigation process adds additional time, as analysts must determine the validity of the alert and gather additional information. While these manual processes are occurring, the potential attacker has been hard at work; likely using scripted or automated processes to probe the network, pivot to other hosts and potential begin exfiltrating data. By the time the security team has verified the threat and begun blocking the attacker, the damage is often already done.

So, how can security operations temporarily contain a possible threat and/or permanently block a known threat? This blog will explain how by utilizing the IncMan SOAR technology from DFLabs with its integration with McAfee Web Gateway, including a use case example in action.

DFLabs and McAfee Web Gateway Integration

McAfee Web Gateway delivers comprehensive security for all aspects of web traffic in one high-performance appliance software architecture. For user-initiated web requests, McAfee Web Gateway first enforces an organization’s internet use policy. For all allowed traffic, it then uses local and global techniques to analyze the nature and intent of all content and active code, providing immediate protection. McAfee Web Gateway can examine the secure sockets layer (SSL) traffic to provide in-depth protection against malicious code or control applications.

Attackers are scripting and automating their attacks, meaning that additional infections and data exfiltration can occur in mere seconds. Security teams must find new ways to keep pace with attackers in order to minimize the impact from even a moderately skilled threat. Utilizing DFLabs IncMan’s integration with McAfee Web Gateway, IncMan’s R3 Rapid Response Runbooks automate and orchestrate the response to newly detected threats on the network, enabling organizations to immediately take containment actions on verified malicious IPs and ports, as well as temporarily preventing additional damage while further investigation is performed on suspicious IP addresses and ports.

Use Case in Action

McAfee Web Gateway has generated an alert based on potentially malicious traffic originating from a host inside the network to an unknown host on the Internet. Based on a predefined Incident Template, IncMan has automatically generated an Incident and notified the Security Operations Team. As part of the Incident Template, the following R3 Runbook has been automatically added to the Incident and executed.

 

Data exfiltration can occur in mere seconds. By the time a security team has validated the threat and blocked the malicious traffic, it is often too late.  DFLabs integration with McAfee Web Gateway allows organizations to automatically contain the threat and stop the bleeding until further action can be taken.

The Runbook begins by performing several basic Enrichment actions, such as gathering WHOIS and reverse DNS information on the destination IP address.  Following these basic Enrichment actions, the Runbook continues by querying two separate threat reputation services for the destination IP address. If either threat reputation service returns threat data above a certain user-defined threshold the Runbook will continue along a path which takes additional action. Otherwise, the Runbook will record all previously gathered data, then end.

If either threat reputation service has deemed the destination IP address to be potentially malicious, the Runbook will continue by using an additional Enrichment action to query the organization’s IT asset inventory.  Although this information will not be utilized by the automated Runbook, it will play an important role in the process shortly.

Next, the Runbook will query a database of known-good hosts for the destination IP address.  In this use case, it is assumed that this external database has been preconfigured by the organization and contains a list of all known-good, whitelisted, external hosts by IP address, hostname and domain. If the destination IP address does not exist in the known-good hosts’ database, the security analyst will be prompted with a User Choice decision. This optional special condition within IncMan will pause the automatic execution of the Runbook, allow the security analyst to review the previously gathered Enrichment information and allow the security analyst to make a conditional flow decision.  In this case, the User Choice decision asks the security analyst if they wish to block the destination IP address. If the analyst chooses to block the destination IP address, a Containment action will utilize McAfee Web Gateway to block the IP until further investigation and remediation can be conducted.

If you want to learn more about how to contain threats, block malicious traffic and halt data exfiltration utilizing Security Orchestration, Automation and Response (SOAR) technology, get in touch with one of the team today to request your live one to one demo.

Key Elements of Every Successful Incident Response Program

Nowadays, businesses face the fact that cyber attacks are part of the overall picture, and will happen at any given moment. Nobody is in doubt about this, and the question has shifted from ‘if they happen’, to ‘when they happen’. Along with this, cybercriminals have become much more sophisticated, raising the costs of fighting back on all industry levels.

Managing cyber security issues can pose a real challenge within a company. The new and complex networks, business requirements for innovation and new ways of delivery of services require new methods and approaches to the way security is handled. Traditional security management methods no longer work. Today, cyber security management should aim towards efficiency when it comes to possible future threats.

Serious data breaches can cost a company hundreds of millions of dollars. Often, what makes a breach serious is the effectiveness and speed of the incident response process.

This being said, creating an incident response program is of utmost importance. It has to excel in the following areas: visibility, incident management, workflows, threat intelligence, and collaboration/information-sharing. Below we’ll take a closer look at each of these areas and discover their importance from a systems level perspective.

Visibility

Having in mind the number of security products in an average company, visibility should be the core of any incident response system – this means aggregating data feeds from commercial and open-source products. When setting up an incident response system, specialists should consider platforms that offer support for security products out of the box. Although not all of them support everything by default, the one you choose should be flexible to add bi-directional integrations with security products not supported by default. But even though bi-directional integrations are important for the support of full automation and orchestration, these are not always necessary for each technology. For example, with simple detection and alerting technologies, unidirectional event forwarding integration will do the work. Just check that common methods of event forwarding and data transfer (such as syslog, database connections, APIs, email and online forms) are supported.

Incident Management

A well-structured incident response program should enable orchestration and automation of the security products that the organization uses. Above everything else, it should include the ability to manage the entire incident response process, starting from the basics, such as tracking cases, recording actions during the incident, as well as reporting on critical metrics and KPIs.

Furthermore, a more advanced incident response system should provide the following:

  • Phase and objective tracking
  • Detailed task tracking, including assignment, time spent and status
  • Asset management — tracking all physical and virtual assets involved in the incident
  • Evidence and chain of custody management
  • Indicator and sample tracking, correlation and sharing
  • Document and report management
  • Time and monetary effort tracking
Process Workflows

One of the key capabilities that should part of the incident response system is the automation and orchestration workflows. The result is more efficient processes and heavy reduction in repetitive tasks for analysts.

These are the core methods for a codification of process workflows: linear-style playbooks or flow-controlled workflows or runbooks.

Both methods have advantages and disadvantages, and as each is suitable for different use cases, they both should be supported by the incident response system. In both cases, workflows should be flexible and support almost any process, and should support the use of built-in and custom integrations, and creating manual tasks that should be completed by an analyst.

Threat Intelligence

The capability of incorporating threat intelligence feeds is one of the most basic requirements for an incident response system. Moreover, with the ability to correlate threat intelligence, it’s easier to discover attack patterns, vulnerabilities, and other current risks without manual analysis. Adding the automated correlation also helps identify whether an ongoing incident shares common factors with any previous incidents. But even though automated correlation is crucial for analysts to make decisions, visual correlation is also important. Visualizations of threat intelligence and correlated events are particularly useful for threat hunting and detecting attacks/patterns that could not have been detected using other methods.

Collaboration and Information-Sharing

Incident response is never a one-person show. Generally, it requires the participation of many people, and often of multiple teams. To be highly effective in such an environment, an incident response system should support seamless collaboration and information-sharing between all stakeholders and team members.

This means that authorized staff members should have access to the status of the incident and other generated information, including team members actions. Also, all staff members should communicate in a secure fashion, using out-of-band communications mechanism.

Furthermore, information-sharing and cooperation should be a regular practice with external entities, especially with law-enforcement agencies. Information-sharing, such as threat intelligence reports, is vital in the fight against cybercrime.

Conclusion

Most companies will experience data breach sooner or later, and how they respond will affect the future of the business. These essential components will help ensure that an organization’s incident response program can detect, contain and mitigate a breach before it can reach more serious status.

Orchestrate Advanced Forensics with DFLabs SOAR and OpenText EnCase

Forensic incidents can be complex and difficult to manage. Large-scale forensic investigations involve dozens or even hundreds of assets, and this information must be recorded, managed and correlated to be effective. DFLabs and OpenText are key partners in delivering these capabilities. This blog post will outline some of the key challenges that security operations are tackling when it comes to effective forensics management, how they can be resolved and briefly present a use case of the integration in action.

Key Challenges

Acquiring forensic data from dozens, even hundreds of potentially impacted hosts across an enterprise can pose a real challenge. This is especially true when these hosts span across continents. Once this data is acquired, it must be organized, enriched and correlated before effective analysis can begin. This results in potentially hundreds of analyst hours lost performing these repetitive tasks before any actual investigative work can take place, during which time, potential attackers could be continuing to further compromise the network or exfiltrate data.

DFLabs integration with EnCase via its IncMan SOAR platform, allows users to more quickly gather critical asset data, manage this data and further enrich this data using IncMan’s orchestration and automation capabilities. It helps to solve these specific security operations challenges often faced by analysts on a daily basis:

  • How can I quickly gather host information from endpoints across my infrastructure?
  • How can I correlate and enrich data collected from across the different hosts in my infrastructure?
  • How can I track my evidence, including acquisition information, location and chain of custody?
  • How can I manage all the findings from my forensic examination in one location, correlate and enrich them?
Complete Forensic and Evidence Management

EnCase from OpenText is the premier digital investigation platform for both law enforcement and private industry. EnCase allows acquisition of data from the greatest variety of devices, including over 25 types of mobile devices such as smartphones, tablets, and GPS devices.  EnCase enables a comprehensive, forensically sound investigation and produces extensive reports on findings while maintaining the evidence integrity. EnCase Enterprise, built specifically for large enterprise clients, allows forensic analysts to reach across the enterprise network, gathering critical forensic data from hosts across a campus or across the world.

By integrating with OpenText EnCase, DFLabs IncMan SOAR can harness the power of EnCase Enterprise Snapshots, making gathering critical forensic artifacts from hosts around the globe a seamless task. Once this information has been collected by EnCase, IncMan automatically organizes this data by host, performs correlation, and allows a user to harness the power of IncMan’s other integrations to further enrich this information.   

In addition to Snapshot information, IncMan is also able to ingest EnCase bookmarks, correlating forensic tools and findings between EnCase cases, as well as acquisition information, making the tracking of forensic clones easier than ever before.

Use Case in Action

An IDS alert for suspicious activity on a host has automatically generated an Incident within IncMan, triggering an investigation. Utilizing IncMan’s EnCase Snapshot EnScript, an analyst performs a snapshot of the host in question, gathering critical process, network and handle information.

Using IncMan’s enrichment capabilities on the newly acquired snapshot information, a suspicious process and several suspicious network connections have been identified, prompting the need for a more detailed forensic investigation.

Utilizing several of IncMan’s containment integrations, traffic from the suspicious IP addresses has been temporarily blocked and the process’s hash value has been banned from running across the environment.

A forensic clone of the host is created to permit a more detailed forensics and root cause analysis. Once the forensic clone is created, IncMan’s Bookmarks and Clones EnScript is used to transfer information regarding the clone from EnCase to IncMan, making tracking the clone’s location and verification simple and easy.

Based on the forensic analysis of the host, a suspicious executable and configuration files have been identified and bookmarked for further analysis. Utilizing IncMan’s Bookmarks and Clones EnScript, these EnCase bookmarks are imported in to IncMan to permit improved tracking and information sharing between analysis.

Making use of one of IncMan’s several integrations with various sandboxing technologies, the executable bookmarked in EnCase is identified as a variant of known malware. Further research on this known malware variant leads to a remediation strategy for the infection of this host.

If you currently use EnCase from OpenText and would like to learn more, request a bespoke one to one demonstration of the integration with DFLabs’ SOAR platform. See for yourself how we can help you to free up valuable analyst time and improve the overall performance of your security program by automating host data acquisitions, tracking and managing important information, while storing all forensic artifacts in a single location for easier use and correlation.

Also for further reading, check out our white paper titled “DFLabs IncMan SOAR: For Incident and Forensics Management”.

How to Perform Threat Hunting and Incident Response on Live Hosts

Performing threat hunting and incident response on live hosts, collectively referred to here as live analysis, can be a complicated task. When performed properly, they can detect and preserve volatile artifacts, such as network connections, running processes, hooks and open files, which may be the only evidence of today’s advanced attacks. Live analysis may also be the only option when taking a host offline for traditional disk forensics is not an option, such as with business-critical application servers or domain controllers. However, if performed improperly, they can alert attackers to your presence, destroy critical information or render any evidence gathered inadmissible in legal proceedings.

Live forensics and live threat hunting

Live forensics and live threat hunting begin as two different processes. When performing live forensics, we typically start with a pivot point; something has already been detected as anomalous which has prompted us to examine the host. During live threat hunting, we are seeking that anomaly, that indicator of potential malicious activity, to use as a pivot point for further investigation. Once that initial indicator has been discovered, the traditional incident response process, often involving further live forensics begins.

Unique challenges

Performing live analysis poses several unique challenges when compared to traditional offline disk forensics. Although any forensic process must be documented and repeatable, these attributes are especially important when performing live analysis. Unlike offline disk forensics, where the original evidence should theoretically remain static and unchanged, live evidence is constantly changing. In fact, we are changing the live evidence by performing live forensics. Although the live analysis process is repeatable, it cannot be repeated while achieving exactly the same results; processes start and end, network connections are terminated, and memory is re-allocated. This means that our live analysis processes must be able to stand up to increased scrutiny.

Because live analysis involves executing commands on a running host, it is crucial that the process is also performed in a secure manner. Only trusted tools should be executed. Each tool and the commands used to execute them should be tested prior to being executed during a live analysis to ensure that the results are known and only the intended actions occur. It is also important to ensure that the tools and commands you tested are the same ones being executed during each live analysis situation.

On Friday, September 7th, I will be speaking at the SANS Threat Hunting and IR Summit in New Orleans regarding some of the challenges and best practices when performing threat hunting and incident response on live hosts. I will also be demoing DFLabs free tool, the No-Script Automation Tool (NAT), which can be used to assist in the live data acquisition process. If you have not had a chance to see NAT, please check out our blog post hereand our demo video here.

Also, find out which top cyber security events DFLabs will attend this fall.

I hope to see you all at the SANS Threat Hunting and IR Summit soon. Safe travels and avoid the storm!