AMP and ThreatGrid Integration into Meraki UTMs

Lately, I have been spending a lot of time on integrating security systems together, and specifically focusing a lot of my energy on Cisco’s Advanced Threat Security product family. (Disclosure: I am employed by Cisco.)

Which is what brings me to Cisco’s Advanced Malware Protection (AMP), which is a solution to enable malware detection, blocking, continuous analysis and retrospective actions and alerting.

In fact, when the Talos cyber-vigilantes parachute into an environment and performs their forensics analysis and active defense against attacks—AMP is one of the primary tools that they use.

Since the acquisition of SourceFire, Cisco has been integrating AMP into many other security products such as: FirePOWER NGIPS’s, Firepower NGFW’s, Cisco (Ironport) Web Security Appliances (WSA), Cisco Ironport Email Security Appliances (ESA), as well as the Meraki MX Security Appliances.

In my opinion, Meraki typically looks at things a bit differently than traditional products, including traditional Cisco product lines. My interpretation of the Meraki approach is that they follow an approach that prioritizes ease-of-operation and management as the No. 1 priority. This means their interfaces tend to keep things simple instead of providing all the many options and nerd-knobs that are traditional at Cisco. The Meraki MX certainly continues that paradigm, and that is the main focus of this article.

I use the MX a lot when I need a good UTM to be deployed at remote locations, but still have centralized management. The MX has Snort running on it for for Intrusion Detection and Prevention. Then Meraki added Advanced Malware Protection (AMP) to the MX with centralized whitelisted URLs and whitelisted files. 

The latest Threat Protection feature to be added to the MX security appliance is an integration with Cisco’s Threat Grid sandboxing and threat intelligence solution.  You may not have known about the release, because Cisco announced the Network Intuitive at the same time, which took the spotlight (naturally).

So, let’s have a quick review of AMP, how Threat Grid plays within the AMP story, and then how that works with the Meraki MX.

Once upon a time, there was a startup company named Immunet AV. They took a fresh and different approach to endpoint security where they kept the security intelligence in the cloud, which helps to maintain a lightweight footprint on the endpoint. Also by keeping the intelligence in the cloud instead of downloading a giant database of signatures to the endpoint, ensures the intelligence is as up-to-date as possible.

As files that are moved/copied/executed within the endpoint, the Immunet client (called a cloud connector) grabs a SHA hash of the file (like this: 0723932d68702a59c4c8bf6a670a098cd55c39f4a3037fa8c2e6d2641fbfe85f) and sends that hash to the cloud where the hash is compared to a giant database of file hashes and their disposition (clean, malicious or unknown).

Fast forward a few years and Marty Roesch, the creator of Snort & founder of SourceFire, likes this technology and the vision of it, and, bam! SourceFire acquires them January of 2008. The solution is renamed to FireAMP, and many still call it that today.

After Cisco acquired SourceFire in 2013, the product was renamed to Advanced Malware Protection (AMP), and it’s been integrated into many security products and services. While a consumer version of Immunet AV is still available for free, it does not have all the features and functions of the commercial version. 

These days, AMP connectors run on endpoints, as well as the network security products, like the Meraki MX. The basic explanation is: When a file traverses one of the devices with an AMP connector, AMP grabs a SHA hash of the file and sends it to the cloud to learn the file’s disposition. If a file hash is known to be malicious, then it can be blocked. If it’s clean, let the file go on through, but make note that the hash was seen & what date/time, etc. Unknown is often up to you, the admin. In many cases, based on your defined settings, unknown files can be sent off to Threat Grid for dynamic analysis.

Note: With AMP, files are never sent to the cloud, only the hash of the file. However, in order for Threat Grid to properly analyze a file and the file’s behavior (think executable or macro-enabled word document), the file must be uploaded into the sandbox.

Now let’s take a look at how the Meraki team performed their magic to make it all simple. They first integrated with AMP. The configuration can be found under Security Appliance > Threat Protection. As you can see in Figure 1, AMP integration can be Enabled or Disabled. You can add whitelisted URLs, and you can add whitelisted SHA256 hashes.

That’s it! Keeping it simple.

What about Threat Grid? We need to be able to send those unknown files over for sandboxing and analysis. That is just below the AMP section on the configuration page, and as you can see in Figure 2, it is also very simple: enabled/disabled, and rate limiting the appliance to a certain number of submissions per day.

Why would anyone want to limit the number of submissions to Threat Grid? Well, it’s because dynamic analysis is not cheap and Threat Grid pricing is all based on “submission packs,” which is a license for the number of submissions per day.

Threat Grid has two form-factors. It can be the more common cloud-service model, or it can be an on-premise appliance for those environments who are worried about sending files into the cloud. Well, the folks in the Meraki team thought of that, too. You can configure your Threat Grid integration to go to either the cloud, or to an on-premise appliance.

That configuration is under Organization > Settings, and this is where you go to link your MXs to a Threat Grid instance (cloud or appliance), as seen in Figure 3.

Well, that about does it for this light write-up. Be on the lookout for some future articles where I will dive deeper into many of these very powerful technologies.