Written in collaboration with John Moran, Senior Product Manager, DFLabs

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 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 with automated malware analysis, can also be used to provide this kind of threat intelligence in near real-time, much faster and more cost effectively than manual analysis.

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.

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

Threat Grid provides a Threat Score, based on the Behavioral Indicators of the activity of the sample. In the example below, the sample has a unique hash value, but its mutex (assigned memory place and name) is the same as the identified remote access Trojan Poison Ivy.

Other Behavioral Indicators provide additional insights into the threat, such as modify the Registry for persistence and outbound communication.

Follow the detonation and report from 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 Threat Grid for IP reputation information for each of the IP addresses. If 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.

Simultaneously, the Runbook queries Cisco Umbrella Investigate for domains associated with the IP addresses found during the executable analysis by 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 Threat Grid. If Threat Grid returns negative reputation results exceeding a user defined threshold, the domain will automatically be blocked using 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.

Additional threat intelligence can be found by pivoting into the Umbrella Investigate report.

The final simultaneous action is a query of the EDR solution for evidence of execution of the executable's hash value returned by 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, integrated with Cisco Security, register now for the upcoming webinar on Tuesday October 30, at 11am EST / 4pm CET, hosted by DFLabs.