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

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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6306
Published: 2014-08-22
Unspecified vulnerability on IBM Power 7 Systems 740 before 740.70 01Ax740_121, 760 before 760.40 Ax760_078, and 770 before 770.30 01Ax770_062 allows local users to gain Service Processor privileges via unknown vectors.

CVE-2014-0232
Published: 2014-08-22
Multiple cross-site scripting (XSS) vulnerabilities in framework/common/webcommon/includes/messages.ftl in Apache OFBiz 11.04.01 before 11.04.05 and 12.04.01 before 12.04.04 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, which are not properly handled in a (1)...

CVE-2014-3525
Published: 2014-08-22
Unspecified vulnerability in Apache Traffic Server 4.2.1.1 and 5.x before 5.0.1 has unknown impact and attack vectors, possibly related to health checks.

CVE-2014-3563
Published: 2014-08-22
Multiple unspecified vulnerabilities in Salt (aka SaltStack) before 2014.1.10 allow local users to have an unspecified impact via vectors related to temporary file creation in (1) seed.py, (2) salt-ssh, or (3) salt-cloud.

CVE-2014-3587
Published: 2014-08-22
Integer overflow in the cdf_read_property_info function in cdf.c in file through 5.19, as used in the Fileinfo component in PHP before 5.4.32 and 5.5.x before 5.5.16, allows remote attackers to cause a denial of service (application crash) via a crafted CDF file. NOTE: this vulnerability exists bec...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.