We spent the first two posts in this series talking about the why (Introduction) and the how (Detecting Today’s Malware) of detecting malware on the network. But that kind of assumes the network is the right place to detect malware. As many Hollywood types tend to do, let’s divulge the answer at the beginning of the post in a transparent plot ploy. Drum roll please… You want to do malware detection everywhere you can. On the endpoints, at the content layer, as well as on the network. It’s not an either/or decision. But that doesn’t mean each approach doesn’t have strengths and weaknesses. So let’s dig into those pros and cons and give you some information to figure out what mix of these different options makes sense for you.
If we recall back to the last post (Detecting Today’s Malware), you have a malware profile of something bad. Now comes the fun part, you have to actually look for it and perhaps even block it before it wreaks havoc in your environment. You also need to make sure you aren’t flagging things unnecessarily (the dreaded false positive), so care must be taken when you decide to actually block something. Let’s weigh the pros/cons of all of the different places we can detect malware and put together a plan to minimize the impact of these malware attacks.
Traditional Endpoint-Centric Approaches
If we jump in the time machine and go back to the beginning of Age of Computer Viruses (right, like 1991), the big threat vector was “sneakernet,” or the proliferation of viruses via floppy disks. In that case, detection made sense to do on the actual endpoint, since that was how the virus spread. So that started an almost 20 year fiesta (for the endpoint protection vendors anyway), where anti-virus technologies became pervasive on the endpoints, evolving three or four steps behind the attacks. So the perception (which isn’t far from reality) regarding the ineffectiveness of endpoint protection remains.
Does that mean it’s not worth doing anymore? Of course not, for a couple of reasons. First and foremost, most organizations just can’t decide to ditch their endpoint protection because it’s a mandated control for many regulatory hierarchies. Moreover, your endpoints are not always connected to your network, and as such they can’t rely on the protection of the mothership. So at a minimum, you still need some kind of endpoint protection on the mobile devices.
Additionally, your network-based controls are not fool-proof, so having another (even somewhat ineffective) layer of protection usually doesn’t hurt. Also remember keeping anything up to date on thousands of endpoints is a challenge, and those complexities shouldn’t be minimized. Finally, by the time your endpoint protection takes a crack at detection, the malware has already entered your network, which historically has not ended well. Obviously, the earlier and closer to the perimeter you can stop the malware, the better.
Detecting malware is one thing, but how do you control it on the endpoints? You’ve got a couple of options:
- Endpoint Protection Suite: Traditional AV (and anti-spyware and anti-everything else). The reality is that most of these tools already use some kind of advance heuristics, reputation matching, and cloud assistance to more accurately detect malware files. But test results don’t lie, these offerings still don’t catch enough and even if the detection rate is 80% (which it probably isn’t) across your 10,000 endpoints, you will be spending 30-40 hours a day cleaning up infected endpoints.
- Browser isolation: Running a protected browser logically isolated from the rest of the device basically puts the malware in a jail where it can’t hurt the law-abiding citizens of your operating system. When malware executes, you just reset the browser without impacting any of the base O/S or device. This represents a more customer friendly approach than requiring browsing in a full virtual machine, but can the browser ever be truly isolated? The answer is no, but this layer of protection allows users to do stupid things without hurting themselves (or you).
- Application White listing: Always an option for truly locking down specific devices, application white listing implements a positive security model on each endpoint. Meaning you specify all of the things that can run, and block everything else. Malware can’t run (because it’s not authorized), and alerts can be fired if a malware-like activity is attempted on the device. To be clear, if you have devices where draconian lock-down is an option, AWL makes a different. But those devices tend to be a large minority of what runs in your environment, making AWL a niche option.
Remember, we aren’t talking about an either/or decision. You’ll be using one (or more) of these options, regardless of what you do on the network for malware detection.
Content Security Gateways
The next layer we saw develop in terms of malware detection was the content security gateway. This happened about the time LAN-based email became pervasive, as a result of folks realizing that sneakernet was horribly inefficient when the bad guys could just send the virus around via email. Ah, the good old days of self-proliferating worms. Thus a set of email (and subsequently web) gateway devices were implemented with anti-virus engines embedded to move detection closer to the perimeter.
Give that many attacks continue to originate via email-based social engineering attacks, in the form of phishing emails either with the payload attached or more likely including links to a malware site or even malware embedded within the HTML message. These gateways can detect and block the malware at any point during the attack cycle by stopping attached malware, blocking the user from navigating to a compromised web site or inspecting the web traffic on the way in and detecting attack code. Many of these gateways also use DLP-like techniques to ensure that sensitive files don’t leave the network via email or web sessions, which is all good.
The weakness of the content gateways resemble the issues with endpoint-based techniques, and that involves keeping pace with the rapid evolution of malware. Email and web gateways do have a positive impact on stopping the proverbial low hanging malware fruit (those easy to detect), by blocking spam messages preventing the user from doing something stupid, as well as blocking the user from navigating to a compromised site. Yet in reality, these devices (or email/web-based cloud-services) don’t have much of a chance against sophisticated malware since their detection mechanisms are based largely upon old-school signatures. Also keep in mind, once the gateway allows a message to pass through (or a web site to be browsed), the gateway is largely blind. It has no way to figure out if a device was compromised, nor remediate the device after the fact.
Network
Now let’s take a look at detecting malware on the network. In reality this means the perimeter of your networks, but some organizations do have network security devices deployed internally, so you should factor that into your architecture, if appropriate. Given the ubiquity of network security devices, doing some level of detection on these devices makes sense. Those deployed on the perimeter tend to see (and inspect) most, if not all, the ingress traffic, so malware could be detected on the perimeter before it can hurt anything. These devices can (and should) also scrutinize egress traffic, looking for sensitive data and/or command and control (C&C) traffic indicating malware that has eluded the initial defenses.
We spent the entire post talking about methods to detect malware on the network, so there is no need to rehash that content.
So what’s the catch? Basically it’s scalability, as malware detection can be pretty resource intensive. This hearkens back to the semi-religious battle surrounding unified threat management (UTM) devices over the past few years. If you recall, UTM was soundly thrashed in enterprise circles because not many believed gateway devices could scale to inspect traffic and do malware analysis at the near-wire speeds required for a network security device. Three years ago, these detractors were not wrong. Yet, the only constant in the security business is change, and a few things have turned the tide here. First is nomenclature. Yesterday’s enterprise UTM device is now called a next-generation firewall. Though the underlying technology of the NGFW fundamentally differs from a traditional UTM (for more details check out our Enterprise Firewall research), both of these devices provide similar capabilities to the customer - the ability to enforce application-oriented policies on network traffic.
The second enabler for network security perimeter consolidation is technology evolution. Chips get faster, algorithms improve, and cloud-based resources provide both compute power and much greater scalability for analysis than was previously capable on a stand-alone perimeter gateway. So the reality is the times they are a changing, and it’s time to revisit the ability of your network devices to detect malware.
We tend to hate to jump on a bandwagon, but we can’t minimize the importance of the innovative technical architectures of NGFW devices hitting the market now. These purpose-built devices process packets differently and enable a much cleaner analysis of the network traffic, enabling many of these sophisticated functions (including malware detection). Combined with the ability to farm some of the compute overhead and network-effect of shared malware profiles into the cloud, suffice it to say we believe some sort of network-based malware detection will emerge as a key security control over the next 18-24 months. Mostly because you need all the help you can get and as we discussed relative to the issues of endpoint protection, the closer to the boundary of your network you can detect and block an attack, the better.
But we understand the pragmatist in you continues to be skeptical of doing yet another function on the same box. Per usual, the vendors have provided another device to sit right next to your existing perimeter security gateway and do malware detection. So can you do malware detection on the same device? In good flip-flopper form (there is a US Presidential election coming up, after all), the answer depends on how much traffic needs to be analyzed and how the device leverages cloud services for analysis of the malware.
We can’t really wrap up this series on network-based malware detection until we dig much deeper into the latter concept - how these gateways leverage the cloud, providing the ability of the network security devices to scale. So that’s the topic of the final post.
- Mike Rothman (0) Comments