As we wrap up Network-based Malware Detection 2.0, the areas of most rapid change have been scalability and accuracy. That said, getting the greatest impact on your security posture from NBMD requires a number of critical decisions. You need to determine how the cloud fits into your plans. Early NBMD devices evaluated malware within the device (on-box sandbox), but recent advances and new offerings have moved some or all the analysis to cloud compute farms. You also need to figure out whether to deploy the device inline, in order to block malware before it gets in. Blocking whatever you can may sound like an easy decision, but there are trade-offs to consider – as there always are.

To Cloud or Not to Cloud?

On-box or in-cloud malware analysis has become one of those religious battlegrounds vendors use to differentiate their offerings from one another. Each company in this space has a 70-slide deck to blow holes in the competition’s approach. But we have no use for technology religion so let’s take an objective look at the options. Since the on-box analysis of early devices, many recent offerings have shifted to cloud-based malware analysis. The biggest advantage to local analysis is reduced latency – you don’t need to send the file anywhere so you get a quick verdict.

But there are legitimate issues with on-device analysis, starting with scalability. You need to evaluate every file that comes in through every ingress point unless you can immediately tell that it’s bad from a file hash match. That require an analysis capability on every Internet connection to avoid missing something. Depending on your network architecture this may be a serious problem, unless you have centralized both ingress and egress to a small number of locations. But for distributed networks with many ingress points the on-device approach is likely to be quite expensive.

In the previous post we presented the 2nd Derivative Effect (2DE), whereby customers benefit from the network effect of working with a vendor who analyzes a large quantity of malware across many customers. The 2DE affects the cloud analysis choice two ways. First, with local analysis, malware determinations need to be sent up to a central distribution point, normalized, de-duped, and then distributed to the rest of the network. That added step extends the window of exposure to the malware. Second, the actual indicators and tests need to be distributed to all on-premise devices so they can take advantage of the latest tests and data. Cloud analysis effectively provides a central repository for all file hashes, indicators, and testing – significantly simplifying data management.

We expect cloud-based malware analysis to prevail over time. But your internal analysis may well determine that latency is more important than cost, scalability, and management overhead – and we’re fine with that. Just make sure you understand the trade-offs before making a decision.

Inline versus out-of-band

The next deployment crossroads is deciding where NMBD devices sits in the network flow. Is the device deployed inline so it can block traffic? Or will it be used more as a monitor, inspecting traffic and sending alerts when malware goes past? We see the vast majority of NBMD devices currently deployed out-of-band – delaying the delivery of files during analysis (whether on-box or in the cloud) tends to go over like a lead balloon with employees. They want their files (or apps) now, and they show remarkably little interest in how controlling malware risk may impact their ability to work.

All things being equal, why wouldn’t you go inline, for the ability to get rid of malware before it can infect anything? Isn’t that the whole point of NBMD? It is, but inline deployment is a high wire act. Block the wrong file or break a web app and there is hell to pay. If the NBMD device you championed goes down and fails closed – blocking everything – you may as well start working on your resume. That’s why most folks deploy NBMD out-of-band for quite some time, until they are comfortable it won’t break anything important.

But of course out-of-band deployment has its own downsides, well beyond a limited ability to block attacks before it’s too late. The real liability with out-of-band deployment is working through the alerts. Remember – each alert requires someone to do something. The alert must be investigated, and the malware identified quickly enough to contain any damage. Depending on staffing, you may be cleaning up a mess even when the NBMD device flags a file as malware. That has serious ramifications for the NMBD value proposition.

In the long run we don’t see much question. NBMD will reside within the perimeter security gateway. That’s our term for the single box that encompasses NGFW, NGIPS, web filter, and other capabilities. We see this consolidation already, and it will not stop. So NMBD will inherently be inline. Then you get a choice of whether or not to block certain file types or malware attacks. Architecture goes away as a factor, and you get a pure choice: blocking or alerting. Deploying the device inline gives the best of both worlds and the choice.

The Egress Factor

This series focuses on the detection part of the malware lifecycle. But we need to at least touch on preventative techniques available to ensure bad stuff doesn’t leave your network, even if the malware gets in. Remember the Securosis Data Breach Triangle. If you break the egress leg and stop exfiltration you have stopped the breach. It’s simple to say, but not to do. Everything is now encapsulated on port 80 or 443, and we have new means of exfiltration. We have seen tampering with consumer storage protocols (Google Drive/Dropbox) to slip files out of a network, as well as exfiltration 140 characters at a time through Twitter. Attackers can be pretty slick.

So what to do? Get back to aggressive egress filtering on your perimeter and block the unknown. If you cannot identify an application in the outbound stream, block it. This requires NGFW-type application inspection and classification capabilities and a broad application library, but ultimately you should be able to take an egress default deny posture. This allows certain applications to send data out of your network, while everything else is blocked.

As we discussed in Network-based Threat Intelligence, you can block traffic to known bad websites as well. You use a list of known malware sites and other places you don’t want employees communicating with, and set your egress filter to block traffic to that IP blacklist. Of course keep in mind that this approach still has all the standard blacklist limitations, so you need to be selective about what you block (versus merely alerting), and keeping the list current can be challenging.

Combining a whitelist of approved applications with a blacklist of bad locations can increase the effectiveness of egress filtering to stop exfiltration before it’s too late.

With that we put a bow on our NBMD 2.0 series. We will assemble this into a paper over the next few weeks, so if you have any last minute comments please let us know – and keep your eyes peeled for the final product.