Advanced threats are continuously evolving and so must our ability to detect, understand, and stop them. Indicators of Compromise are vital to this process. At Cisco, our approach to developing Indicators of Compromise and interpreting them is continuously evolving to empower you with the best intelligence to thwart stealthy attacks.
Not only the Indicators themselves, but the process for producing them needs to be dynamic and able to adapt to changing conditions. Cisco AMP Threat Grid tackles this challenge by automating the entire process, including the analyst’s approach to making a determination.
Thinking about Indicator creation in this way leads to additional questions and steps that involve frequency analysis, clustering, tagging, variable scoring models, and the application of historical analyses and enriched content to the generation of Indicators.
Why are we expending so much effort on Indicators? It’s simple; Indicators are the first step in applying context to the analysis we produce. We see hundreds of thousands of submissions a day pass through the AMP Threat Grid analysis engine. This generates a huge wealth of data including PCAPs, Disk, Memory and Network Artifacts, entities such as registry entries, file paths, network activity, process information, and more. All of this is searchable and extractable via our UI or API. There is no context though. Generating context through the application of knowledge allows for the creation of intelligence that is actionable and specific to the organization that requested it.
AMP Threat Grid solves various use cases and the challenges they pose. As an example, let’s consider Security Operations Centers or SOCs. They typically follow a tiered model when it comes to staffing – junior or Tier 1 analysts through to Tier 3 or 4 specialists. With the volume of commodity malware today it is simply not scalable to expect the specialists on your team to deal with daily infections of banking Trojans or DDoS bots or Bitcoin miners. A process should be defined for each so that they can be treated as expeditiously as a password reset request. Detect, remediate, and move on. How do you operationalize the Tier 1 analyst to be able to effectively respond to an infection of this sort? Context.
Since we began creating Indicators for our data, we’ve always tried to consider the various user types and their areas of expertise. We cannot expect everyone to look at thousands of lines of output and know, for example, that the CurrentControlSet key that was created was not simply operating system noise but a means of persisting on the host. Each of our Indicators includes a detailed description of the activity, why it might be used by a malware author, and the analysis entities that triggered the Indicator. By providing detailed and educational descriptions as well as the actionable content we’re not simply ensuring the analysts have the data to quickly respond. We are also providing an educational platform where analysts constantly gain knowledge and insight into malware and the various techniques leveraged, all the while reducing the total time of an incident. This has the added benefit of freeing up the technical specialists to focus on the attacks and events that are truly critical to the security of an enterprise.
Context allows us to better address threat content enrichment, threat intelligence creation, automation, and integration to improve response, security operations, and help drive enterprises in implementing an intelligence-driven security model.
Next time we’ll take a look at the role of AMP Threat Grid as part of an integrated workflow for response.
As a result of Cisco’s acquisition last May, ThreatGRID is now part of the Cisco Advanced Malware Protection (AMP) portfolio as AMP Threat Grid. The acquisition expands Cisco AMP capabilities in the areas of dynamic analysis and threat intelligence technology, both on-premise and in the cloud. AMP Threat Grid extends Cisco AMP with even greater visibility, context, and control over sophisticated threats. Security analysts and incident response teams can augment their forensics analysis to detect and stop evasive attacks faster than ever.
AMP Threat Grid is not simply another dynamic analysis platform or sandbox. While the solution does leverage various dynamic analysis techniques and ‘sandboxing’ to produce content, it also acts as a content engine so that you can more quickly and easily extract insights from the data. AMP Threat Grid treats all of its analysis as content, making it available to the user via a portal or API. AMP Threat Grid also doesn’t stop at a single analysis technique; instead it applies multiple dynamic and static analysis engines to submitted samples – all produced disk, network, and memory artifacts – in order to generate as rich a source of data as possible.
This post is co-authored by Andrew Tsonchev, Jaeson Schultz, Alex Chiu, Seth Hanford, Craig Williams, Steven Poulson, and Joel Esler. Special thanks to co-author Brandon Stultz for the exploit reverse engineering.
Silverlight exploits are the drive-by flavor of the month. Exploit Kit (EK) owners are adding Silverlight to their update releases, and since April 23rd we have observed substantial traffic (often from Malvertising) being driven to Angler instances partially using Silverlight exploits. In fact in this particular Angler campaign, the attack is more specifically targeted at Flash and Silverlight vulnerabilities and though Java is available and an included reference in the original attack landing pages, it’s never triggered.
Cisco Security Intelligence Operations is tracking reports of ongoing exploitation of a vulnerability in the popular web application framework Ruby on Rails that creates a Linux-based botnet. The vulnerability dates back to January 2013 and affects Ruby on Rails versions prior to 3.2.11, 3.1.10, 3.0.19, and 2.3.15. Cisco Security Intelligence Operations’ has previously published an analysis of CVE-2013-0156. Cisco is receiving reports of attempted infection from Cisco IPS customers participating in Global Correlation.