Attacks/Breaches
5/28/2013
09:31 AM
Mike Rothman
Mike Rothman
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

The Network And The Malware

This is the first installment of a two-part series in which Mike Rothman and Wendy Nather will tackle how to use the network for detection, monitoring, and forensics of advanced malware

Given the IPO talk for high-flying startups providing network-based advanced malware detection gear and the weekly announcements of incumbent network security players announcing competing products, you'd think the industry has come up with a cure for cancer or some way to entice attackers to stop trying to rob you blind. It hasn't. In fact, as my partner Rich Mogull frequently says, you can't change human behavior -- EVER. So the attackers will pretty much always attack.

The question is, what can you do as a defender to make it harder for the attackers to successfully compromise your environment? It's no secret that well-funded and capable adversaries will defeat your defenses, but you want to make them work for it. If the so-called advanced attackers don't have to use advanced attacks (and they won't unless they have to), then you stink at security. On the other hand, if your high-end, high-priced forensicators find all sorts of 0-day malware and other nonstandard attacks, then you should be happy. OK, maybe not happy, but you should have some small sense of satisfaction that you made it hard on the adversary, while you are cleaning out your desk.

Where was I again? Oh, yeah, the network's role in detecting these advanced malware attacks. Basically we know traditional endpoint protection leaves a lot to be desired against advanced malware (yes, that's a politically correct way of saying it doesn't work). We also know that we can't totally lock down all of our devices, not without having your employees burn you in effigy in the parking lot. That explains the interest in these network-based malware detection devices to help get rid of some of the malware crap before gets into your environment.

The story goes that these devices can detect bad stuff on the perimeter. The sales reps will tell you they've figured out how to stop the APT, make your CIO respect you, and allow you to actually spend a holiday like Memorial Day drinking beer, eating BBQ, and remembering the heroes who defend your homeland -- instead of how you usually spend the holiday, which is trying to figure out how your customer database ended up on Pastebin.

To be clear, you aren't going to be able to block 100 percent of the advanced malware targeting your organization on your perimeter. No matter what the vendor sales rep tells you. But if you can block an incremental 50 percent of the malware before your idiotic users even have a chance to click on the link or open the PDF attachment, is that worth it? You bet it is.

So how does it work? These devices are basically sophisticated sandboxes that execute inbound files within an allegedly safe environment either on the box or in a cloud-based sandbox to determine whether the file exhibits bad behavior and therefore would be malware. Of course, it's a little more complicated than that, but that's the general concept. There is a religious battle brewing between those folks who think you should have the sandbox on the device and those who think you need to use a cloud-based environment to test the malware. I think over time the cloud-based approach will prevail, but either way the idea of analyzing files before they end up on your devices is a good thing.

Another value of this network-based approach is these devices also monitor egress traffic to detect communications between a potentially compromised device and a command-and-control network. So in the event the box misses the malware on the way in (and a percentage of the time it will), you get a chance to detect when the malware is connecting to its master.

Yet the malware arms race continues. The attackers are learning how these devices work and will develop evasion techniques to defeat these devices, too. That's the way of the world. That means you need to break out your Security 101 manual and revisit the layered defense doctrine. You'll need to make additional investments on complementary advanced malware technology that runs on your endpoint. You'll need to make sure you don't fall behind on keeping your devices patched and configured correctly.

But also importantly, you'll need to focus on being able to shorten the window between exploit, detection, and remediation. And, yes, the network plays a big role in the "after compromise" aspects of dealing with advanced malware.

In Part 2 of this series, my friend Wendy Nather will delve into how detection turns into network forensics and provide some tips on how you can figure out what just happened to you.

Mike Rothman is President of Securosis and author of The Pragmatic CSO

Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web